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L'invention concerne un systeme d'acces a un reseau adapte pour la 
mise en oeuvre d'un precede a signature simplifiee, et un serveur pour sa 
realisation. 

Plus pre.cisement, l'invention concerne un systeme comportant : 

- au moins un poste d'utilisateur equipe d'un navigateur internet, 

- un serveur proxy par lequel passent tous les flux d'informations 
echanges entre le ou chaque poste d'utilisateur et ledit reseau, 

- plusieurs fournisseurs de services raccordes audit reseau, 
chaque fournisseur de services etant apte a emettre une requete 
d'authentification vers le poste de I'utilisateur qui le contacte pour identifier et/ou 
authentifier cet utilisateur avant de lui fournir des services personnalises et/ou 
securises, la reponse a fournir par un meme utilisateur a cette requete 
d'authentification pouvant etre differente en fonction du fournisseur de services 
contacte, 

- au moins un serveur d'authentification propre a memoriser :au 
moins une information d'authentification pour chaque utilisateur et a transmettre; 
en reponse a une requete d'authentification une reponse d'authentificatipjv 
contenant une information d'authentification fonction a la fois du fournisseur. de 
services ayant ernis la requete d'authentification, et de I'identite de Tutifisateur 
ayant contacte ce fournisseur de services, et 

- un module a signature simplifiee apte a traiter automatiquement 
en lieu et place du ou de chaque poste d'utilisateur les requetes 
d'authentification emises par les fournisseurs de services contactes, ce module 
etant apte pour chaque utilisateur : 

- a diriger les requetes d'authentification vers le serveur 
d'authentification approprie, et 

- a retransmettre au fournisseur de services la reponse 
d'authentification correspondante transmise par le serveur d'authentification 
approprie. 

Ces systemes permettent de mettre en oeuvre un procede a 
signature simplifiee plus connu sous les termes de procede SSO ("Single Sign 
On" ou "Simplified Sign On"). Des renseignements plus precis sur un exemple 
de procede SSO peuvent etre obtenus a la lecture des recommandations 
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definies par le consortium d'entreprises appele Liberty Alliance, dont le but est 
le developpement des transactions sur Internet. Ces recommandations peuvent 
par exernple, etre obtenues a partir du site Internet http://www.projectliberty.org. 

Les precedes SSO visent a simplifier ('identification et/ou 
5 I'authentification d'un utilisateur sur la toile d'araignee mondiale plus connue 
sous les termes de WEB (World Wide Web). Dans la suite de cette description, 
la toile d'araignee mondiale sera simplement designee par le terme reseau 
internet. 

Les precedes SSO et notamment ceux conformes aux 
10 recommandations de Liberty Alliance, implemented le module a signature 
simplifiee dans le serveur proxy. Toutefois, cette solution presente 
I'inconvenient qu'elle implique des modifications substantielles des serveurs 
proxy existants et qu'elle suppose une augmentation des traitements a realises 
par les serveurs proxy existants. 
15 L'invention vise a remedier a cet inconvenient en proposant un 

systeme d'acces a un reseau a commutation de paquets adapte pour la mise 
en oeuvre d'un precede SSO dans lequel les modifications a apporter au 
serveur proxy sont mineures et les consequences sur la charge a traiter sont 
mineures. 

20 L'invention a done pour objet un systeme tel que decrit ci-dessus, 

caracterise en ce qu'il comporte un serveur supplemental independant du 
serveur proxy, le module a signature simplifiee etant implements dans ce 
serveur supplementaire, et en ce que le serveur proxy est equipe d'une 
interface permettant de raccorder le serveur supplementaire et de transmettre 

25 au moins les requetes d'authentification emises par les fournisseurs de services 
contactes audit serveur supplementaire pour traitement de ces requetes par le 
nodule a signature simplifiee. 
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- ladite au moins une information d'authentification memorisee pour 
chaque utilisateur cornprend une information sur un niveau d'authentification 
disponible pour cet utilisateur, en ce que chaque requete d'authentification 
emise par un fournisseur de services specifie des caracteristiques sur le niveau 

5 d'authentification requis par ce fournisseur de services pour pouvoir acceder 
aux services qu'il propose, en ce que le ou chaque serveur d'authentification est 
apte a comparer les caracteristiques sur le niveau d'authentification requis 
sp6cifi§ par la requ§te d'authentification a I'information sur le niveau 
d'authentification disponible, de maniere a determiner si le niveau 

10 d'authentification requis correspond au niveau d'authentification disponible pour 
cet utilisateur, et en ce que le ou chaque serveur d'authentification est apte a 
emettre vers Putiiisateur une requ§te d'authentification active propre a activer 
sur le poste de Putiiisateur un processus interactif d'identification et/ou> 
. d'authentification de Putiiisateur si le niveau d'authentification requis ne • 

15 correspond pas au niveau d'authentification disponible ; 

- le serveur supplemental comporte un sous-module propre a , 
diriger la reponse de Putiiisateur aux requetes d'authentification active vers le • 
serveur d'authentification qui Pa emise ; ; 

- le serveur supplemental comporte un sous module propre a 
20 diriger la requete d'authentification active vers le poste de Putiiisateur ; 

- le module a signature simplifiee comporte un sous-module capable 
d'ajouter aux requetes transmises par le poste d'utilisateur vers un fournisseur 
de services un signal d'identification de service a signature simplifiee en 
reponse auquel le fournisseur de services emet la requete d'authentification ; 

25 - le serveur supplemental et le serveur proxy sont aptes a 

communiquer Pun avec Pautre en mettant en oeuvre un protocole de transfert de 
flux HTTP (Hyper Text Transfer Protocol) ; 

- le protocole de transfert de flux HTTP est le protocole iCAP 
(Internet Content Adaptation Protocol) ou le protocole OCP (OPES Call Out 

30 Protocol). 

- le serveur supplemental est uniquement apte a communiquer 
avec les fournisseurs de services par Pintermediaire du protocole de transfert 
de flux HTTP mis en ceuvre entre lui et le serveur proxy ; 
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- le serveur supplemental implemente egalement un serveur et/ou 
un client HTTP (Hyper Text Transfer Protocol) pour communiquer directement 
avec le ou chaque fournisseur de services et/ou le ou chaque serveur 
d'authentification uniquement a I'aide du protocole HTTP ; 

5 - il comporte un fournisseur d'acces audit reseau auquel doit se 

connecter le ou chaque poste d'utilisateur pour pouvoir acceder audit reseau, 
ce fournisseur d'acces etant equipe du serveur proxy ; 

- ledit reseau est la toile d'araignee mondiale. 

L'invention sera mieux comprise a la lecture de la description qui va 
10 suivre donnee uniquement a titre d'exemple et faite en se referant aux dessins 
sur lesquels : 

- la figure 1 est une illustration schematique de I'architecture d'un 
systeme conforme a I'invention, 

- la figure 2 est un organigramme d'un precede a signature simplifiee 
15 mis en oeuvre dans le systeme de la figure 1 , et 

- les figures 3 et 4 sont des illustrations schematiques de la 
circulation des flux d'informations entre les differents equipements du systeme 
de la figure 1 . 

La figure 1 represente un systeme, designe par la reference generale 
20 2, d'acces a un reseau 4 a commutation de paquets adapt§ pour la mise en 
ceuvre d'un precede SSO conforme aux recommandations definies par Liberty 
Alliance. 

Les recommandations etablies par Liberty Alliance definissent 
i'organisation et les fonctionnalites des differents equipements ou groupes 
25 d'equipements du systeme 2 avec une precision suffisante pour que I'homme 
du metier a la lecture de ces recommandations puisse fabriquer ses 

equipements. Ces rscommsndations ne dec-rivsnt pss is realisation detallle-e ds 
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Le systeme 2 sera ici decrit dans le cas particulier ou le reseau 4 est 
le reseau internet. 

Le systeme 2 comporte de nombreux postes d'utilisateurs ayant des 
fonctionnalites similaires les unes aux autres ainsi que plusieurs fournisseurs 
5 d'acces internet, ayant egalement des fonctionnalites similaires les unes aux 
autres. Ici pour simplifier I'illustration de la figure 1, seul un poste d'utilisateur 1 0 
et un fournisseur d'acces 12 ont ete representes. 

Le poste 10 est apte a naviguer sur le reseau 4. A cet effet, il est 
forme, par exemple, d'un ordinateur conventionnel 14 equipe d'un ecran et d'un 
10 clavier ainsi que d'un navigateur internet 16 plus connu sous le terme anglais 
de "browser". 

Le systeme 2 comporte egalement de nombreux systemes 
fournisseurs de services ainsi que plusieurs serveurs d'authentification. . Ici, 
seuls deux systemes fournisseurs de services 20, 22, designes fournisseurs, 
15 ainsi que deux serveurs d'authentification 24, 26 sont representes sur la figure 
1 pour simplifier I'illustration. 

Les fournisseurs de services 20, 22 sont destines a rendre des 
services a I'utilisateur du poste 10. 

Par exemple, ici, le fournisseur 20 est un serveur informatique propre 
20 a etablir des fiches de paye en fonction des informations qui lui sont 
communiquees par I'utilisateur du poste 10. Pour cela, le serveur 20 comporte 
un module 32 propre a identifier et a authentifier I'utilisateur du poste 10 de 
maniere a personnaliser et a securiser le service qu'il rend a cet utilisateur. Plus 
precisement, le fournisseur 20 est associe a une memoire 30 dans laquelle est 
25 enregistree une liste 34 de serveurs d'authentification connus du fournisseur 20 
ainsi qu'un niveau 36 d'authentification requis par ce fournisseur. 

La liste 34 comporte des identificateurs des serveurs 
d'authentification contenant des informations d'authentification propres a 
identifier et authentifier un utilisateur aupres de ce fournisseur de services. Une 
30 telle information est, par exemple, un niveau d'authentification disponible 
actuellement pour un utilisateur donne. 

Le niveau d'authentification enregistre dans la memoire 30 definit ia 
qualite de I'authentification requise par le fournisseur 20. Dans le systeme 2, a 



titre d'exemple, chaque niveau d'authentification peut prendre Tune quelconque 
des valeurs entieres comprises entre "1" et "5". Plus la valeur du niveau 
d'authentification est petite, plus la qualite de I'authentification est faible. Id, a 
tltre d'exemple, le niveau d'authentification 36 est egal a "2". 

Les fonctions realisees par le module 32 sont decrites plus en detail 
en regard des figures 3 et 4 et Pinteret de la liste 34 ainsi que du niveau 
d'authentification apparaTtra a la lecture de la suite de cette description. On 
mentionnera ici simplement le fait que le module 32 est capable d'emettre une 
requete d'authentification HTTP incluse dans une reponse HTTP pour 
authentifier I'utilisateur vers le poste 1 0 de cet utilisateur. 

Le fournisseur 22 permet, par exemple, a I'utilisateur du poste 10 de 
gerer a distance ses comptes bancaires et d'effectuer egalement des 
transactions bancaires. Le fournisseur 22 comporte les memes elements que . 
ceux decrits en regard du fournisseur 20 a I'exception du fait que le niveau 
d'authentification 36 est remplace par un niveau d'authentification 38 egal a "4". 

Les serveurs d'authentification 24 et 26 sont destines a repondre aux 
requetes d'authentification emises par les fournisseurs de services. A cet effet, 
les serveurs 24 et 26 sont associes chacun a une memoire 40, 41 dans laquelle 
est enregistree pour chaque utilisateur connu de ce serveur, une information 
42, 43 d'authentification. Chaque information d'authentification contient le 
niveau d'authentification disponible pour I'utilisateur correspondant. 

Chaque serveur d'authentification 24, 26 comporte egalement un 
module 44 de controle d'acces. Ce module permet aux serveurs 24 et 26 
d'emettre une requete d'authentification active de maniere a interroger 
I'utilisateur du poste 10 pour que celui-ci fournisse un jeu d'informations 
permettant de ('identifier et de I'authentifier avec un niveau d'authentification 
souhaite. Un jeu ^informations est, parexernpte. un identrncstsur rf* i'nfiife»f».r 
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une adresse reseau au poste 10 pour que celui-ci puisse naviguer sur le reseau 
4. 

A cet effet, il comporte un serveur proxy HTTP (Hyper Text Transfer 
Protocol) et un serveur 52 de contrdle d'acces. Le protocole HTTP existant est 
5 un protocole de communication utilis§ pour les echanges de donnees entre des 
clients HTTP et des serveurs HTTP connus sous les termes de serveur web. Le 
serveur proxy est place en coupure de flux entre le poste 10 et le reseau 4, 
c'est-a-dire que I'ensemble des flux d'informations echanges entre le navigateur 
16 du poste 10 et le reseau 4 passe par I'intermediaire du serveur proxy 50. 
10 Ainsi, le serveur proxy 50 voit passer I'ensemble des requetes et des reponses 
HTTP emises par le poste 10 ou vers le poste 10. 

Le serveur de contrdle d'acces 52 est capable d'identifier et 
d'authentifier I'utilisateur du poste 10 avant d'autorlser ce poste 10 a se. 
connecter au reseau 4 et a naviguer sur celui-ci. Typiquement, I'utilisateur du,. 
15 poste 10 s'identifie aupres du serveur 52 en fournissant un jeu d'informations;.. 
contenant un identificateur connu sous le terme anglais de "login" et un mot de. . 
passe. Si I'utilisateur est correctement identifie et authentifie, c'est-a-dire que le ; - 
jeu informations qu'il a fourni correspond a un abonnement valide aupres de ce-.. 
foumisseur d'acces, le serveur 52 affecte a cet utilisateur une adresse reseau, . 
20 c'est-a-dire ici une adresse IP (Internet Protocol) pour naviguer sur le reseau 4. 
Dans le cas contraire, le serveur 52 interdit toute connexion au reseau 4. 

Le serveur 52 est egalement capable d'enregistrer dans une 
memoire 54 a laquelle il est associe une liste 56 contenant pour chaque 
adresse IP affectee a un utilisateur, I'identificateur de I'utilisateur correspondant. 
25 Cette liste est mise a jour automatiquement par le serveur 52. 

Le foumisseur d'acces 12 comporte un serveur iCAP 60 (Internet 
Content Adaptation Protocol) place a cote du serveur 50 et raccorde a celui-ci 
par Pinterm6diaire d'une liaison filaire 62 ou d'un reseau local. Le protocole 
iCAP existant est normalise par I'organisme IETF (Internet Engineering Task 
30 Force) pour la transformation systematique de contenus sur Internet. Ainsi, le 
serveur 60 et le serveur 50 sont capables de communiquer I'un avec Pautre en 
mettant en ceuvre le protocole iCAP. Plus precisiment, le serveur 50 est apte a 
communiquer au serveur 60 des requites ou des reponses HTTP presentes 



dans les flux d'informations echanges entre le poste 10 et le reseau 4 et le 
serveur 60 est egalement capable de transmettre des requetes ou des 
reponses HTTP apres les avoir modifiees au serveur 50. 

De maniere a implementer un client iCAP dans le serveur proxy 50 
5 celui-ci est equipe d'une interface iCAP 64 comportant un connecteur 
permettant de le raccorder au serveur 60. 

L'interface 64 est ici configuree pour transmettre au serveur 60 
uniquement les requetes ou les reponses HTTP qui doivent etre modifiees pour 
la mise en ceuvre du procede SSO. 
10 Le serveur 60 est equipe d'un module SSO 66 propre a prendre en 

charge tous les traitements specifiques requis par la mise en oeuvre du procede 
SSO. Ce module 66 comporte trois sous-modules 68, 70 et 72 correspondant 
chacun a un service iCAP. Ces sous-modules seront decrits plus en detail en 
regard de chacune des figures 3 et 4. 
15 Le serveur 60 est associe a la memoire 54 qui contient egalement 

une liste 76 des serveurs d'authentification connus par chaque utilisateur. Cette 
liste 76 regroupe pour chaque utilisateur, les identificateurs des differents 
serveurs d'authentification dans lesquels sont memorisees des informations 
d'authentification pour cet utilisateur. 
20 Le serveur 60 implements aussi un client HTTP. A cet effet, il est 

raccorde au reseau 4 par I'intermediaire d'un serveur proxy HTTP 
supplemental 74 qui peut etre independant et distinct du serveur proxy 50. 

L'ensemble des serveurs du systeme 2 sont realises a partir de 
calculateurs electroniques conventionnels programmables aptes a executer des 
instructions enregistrees sur un support d'enregistrement d'informations. A cet 
effet, les memoires 30, 40, 41 et 54 comportent des instructions pour 
['execution du precede SSO des figures 2 a 4 loraque lesdiies instructions sent 
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Parallelement, lors d'une etape 92, les listes 34 des fournisseurs de 
services sont mises a jour. 

Ensuite, I'utilisateur du pdste 10 se connecte, lors d'une etape 94, au 
reseau 4. Lors de cette etape, I'utilisateur saisit, lors d'une operation 96, un jeu 
5 d'informations permettant de identifier et de I'authentifier aupres du serveur 52. 

Une fois que I'utilisateur 10 a ete identifie et authentifie, le serveur 
52, lors d'une operation 98, iui affecte une adresse IP et enregistre ia relation 
entre cette adresse reseau et I'identificateur de cet utilisateur dans la liste 56. 

Ensuite, le serveur 52 informe, lors d'une operation 100, les 
10 differents serveurs d'authentification connus par cet utilisateur que celui-ci a ete 
correctement identifie et authentifie. Cette identification et authentification 
realisee par le serveur 52 est ici associee a un niveau d'authentification egal a 
"2" de sorte que les serveurs d'authentification memorisent que le niveau 
d'authentification disponible est egal a "2". 
15 Une fois autorise a naviguer sur le reseau 4, I'utilisateur se connecte, . 

par exemple, lors d'une etape 104, au fournisseur de services 20. Le module 32 < 
du fournisseur 20 emet alors en reponse, lors d'une operation 106, une requete • 
d'authentification HTTP incluse dans une reponse HTTP a destination du poste , 
10. Cette requete est interceptee par le serveur proxy 50 puis traitee par le 
20 serveur iCAP 60 et enfin transmise jusqu'au serveur d'authentification 24. Cette 
requete d'authentification comporte le niveau d'authentification 36. Le serveur 
24 verifie, lors d'une etape 108, que le niveau d'authentification disponible pour 
cet utilisateur est au moins egal a "2". Ici, le niveau d'authentification disponible 
etant 6gal a celui requis par le fournisseur 20, le serveur 24 transmet, lors d'une 
25 etape 110, une reponse d'authentification contenant un certificat 
d'authentification au fournisseur 20. Ce certificat informe le fournisseur 20 que 
le niveau d'authentification requis est disponible. 

Le fournisseur 20 ayant recu le certificat propose alors, lors d'une 
etape 112, a cet utilisateur un service personnalise et / ou securise sans que 
30 I'utilisateur ait besoin de s'identifier aupres du fournisseur 20. Par exemple, le 
fournisseur 20 Iui propose I'impression d'une feuille de paye comportant son 
nom. 
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Ensuite, toujours lors de la meme connexion, I'utilisateur 10 se 
connecte en 1 14 au fournisseur de services 22. Ce fournisseur 22 execute alors 
I'operation 106. 

Toutefois, contrairement au cas precedent, le serveur 
5 d'authentification 24 constate que le niveau d'authentification requis par le 
fournisseur 22 est superieur a celui actuellement disponible pour cet utilisateur. 

Le module 44 de controle d'acces du serveur 24 procede alors a une 
etape 120 d'authentification active lors de laquelle il interroge I'utilisateur, de 
maniere a identifier et a authentifier celui-ci avec une qualite d'authentification 
10 correspondant au niveau d'authentification "4". Par exemple, le module 44 
demande a I'utilisateur de saisir des informations personnelles telles que sa 
date de naissance. 

Si I'utilisateur du poste 10 a ete correctement identifie et authentifie 
avec un niveau d'authentification "4", le serveur 24 enregistre le nouveau 
15 niveau d'authentification disponible dans sa memoire 40 et procede a I'etape 
110. 

Ensuite, le fournisseur 22 propose lors d'une etape 122 un service 
personnalise et / ou securise a cet utilisateur. 

Le procede ci-dessus decrit dans le cas particulier des fournisseurs 
20 20, 22, est alors reitere au fur et a mesure que I'utilisateur du poste 1 0 contacte 
de nouveaux fournisseurs de services. 

Ainsi, grace a ce procede, I'authentification de I'utilisateur est 
simplifiee puisque celui-ci ne doit s'identifier et s'authentifier que lors de la 
connexion au reseau 4 puis ensuite a chaque fois qu'il contacte un fournisseur 
25 de services exigeant un niveau d'authentification superieur a celui disponible. 
Ce procede pennet done d'eviter a I'utilisateur de saisir, a chaque fois qu'il 
contacte un nouveau fournisseur ;iervic3*, un ieu ^'informations: 
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portent done ies memes references. Les fleches entre ces equipements 
represented a la fois le sens de circulation des informations et les operations 
correspondantes. 

Initialement, ie navigateur 16 du poste 10 envoie une requete HTTP 
vers le module 32 d'un fournisseur de services, par exemple le fournisseur 20. 
Cette requete est acheminee, lors d'une operation 130, jusqu'au serveur proxy 
50. L'interface 64 intercepte cette requete et la transmet, lors d'une operation 
132, au serveur 60 et plus precisement au sous-module 68. Le sous-module 68 
ajoute un en-tete a la requete HTTP indiquant que le systeme 2 supporte un 
procede SSO et retransmet, lors d'une operation 134 cette requete HTTP ainsi 
modifiee vers le serveur proxy 50. 

Le serveur proxy transmet alors la requete HTTP modifiee jusqu'au 
fournisseur de services lors d'une operation 136. 

Le module 32 du fournisseur de services detecte la presence de Pen-; 
tete ajoute par le sous-module 68 et, en reponse, envoie, lors d'une operation - 
138, une requete d'authentification vers le navigateur 16. 

La requete d'authentification est, par exemple, conforme au 
protocole SOAP (Single Object Access Protocol) normalise par I'organisme. . 
W3C (World Wide Web Consortium). 

Cette requete d'authentification comporte notamment un identifiant 
du fournisseur de services, une copie de la liste 34 de serveurs 
d'authentification connus, le niveau d'authentification requis par ce fournisseur 
et, par exemple, une instruction connue sous les termes anglais "set cookie" 
destinee a enregistrer un identificateur de la requete d'authentification sur le 
poste 10 ou, en variante, directement un identifiant de la requete. 

L'interface 64 du serveur proxy 50 intercepte cette requete 
d'authentification et la dirige, lors d'une operation 140, vers le sous-module 70 
du serveur 60. 

Le sous-module 70 compare, lors d'une operation 142, la liste 34 
regue a la liste 56 pour selectionner le serveur d'authentification a contacter, 
par exemple, ici le serveur 24. S'il n'existe aucun serveur d'authentification 
commun & la liste 34 regue et a la liste 56, le sous-module 70 envoie ur. 
message d'incompatibilite au fournisseur de services ayant emis la requete 
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d'authentification. Ce message d'incompatibilite comporte I'identificateur de la 
requete d'authentification, de maniere a ce que le module 32 puisse relier cette 
reponse a la requete d'authentification correspondante. L'ident'rficateur de la 
requete d'authentification est, par exemple, celui contenu dans I'instruction "set 
5 cookie". 

Ensuite, le sous-module 70 determine, lors d'une operation 144, 
I'identite de I'utilisateur du poste 10 en comparant i'adresse reseau du poste 10 
a la liste 76. Cette adresse aura ete foumie par le serveur proxy 50 au sous- 
module 70 lors de I'operation 140 par I'intermediaire d'un champ de I'en-tete 
10 HTTP. 

Une fois I'utilisateur identifie, le sous-module 70 procede a une 
operation 148 de transmission de la requete d'authentification regue associee a 
I'identificateur de I'utilisateur obtenu lors de I'operation 144, au serveur 
d'authentification selectionne lors de I'operation 142. 
15 Le serveur 24 compare, lors d'une operation 150, le niveau 

d'authentification disponible pour I'utilisateur a celui requis par le fournisseur de 
services. 

Dans le cas oD le niveau d'authentification requis est superieur a 
celui actuellement enregistre par le serveur 24, celui-ci procede comme decrit 
20 en regard de la figure 4. 

Dans le cas contraire, le serveur 24 envoie lors d'une operation 152, 
une reponse d'authentification au serveur 60. 

Le sous-module 70 recoit la reponse d'authentification et la transmet, 
lors d'une operation 156, vers le fournisseur de services par I'intermediaire du 
25 serveur proxy 74 et en utilisant le protocole HTTP. Cette reponse 
d'authentification comporte si necessaire un identificateur de I'utilisateur. 

Le fournisseur de services repond a cette reponse d'authentification 
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Ainsi, une page d'accueil personnalisee s'affiche sur le navigateur 16 
de Putilisateur du poste 10 sans meme que cet utiiisateur ait eu besoin de 
s'identifier aupres, par exernple, du fournisseur 20. 

La figure 4 represente la circulation des informations entre les 
5 differents equipements du systeme 2 dans le cas particulier ou le niveau 
d'authentification requis par le fournisseur de services contacte est superieur a 
celui actuellement memorise dans la m6moire 40 du serveur 24. Sur cette 
figure, les equipements et les operations deja decrits en regard des figures 1 et 
3 portent les memes references et les nouvelles operations sont representees 
10 en traits gras. 

Lors de Pop6ration 150, le serveur 24 a etabli que le niveau 
d'authentification requis est superieur a celui actuellement disponible pour. 
Putilisateur. Par consequent, il procede a une operation 180 lors de laquelle le".. 
module 44 transmet une requete d'authentification active vers le serveur 60- 
15 contenue dans une reponse HTTP et en utilisant le protocole HTTP, La requete. 
d'authentification active est destinee a activer sur le navigateur 16 un processus* 
d'authentification interactif. A cet effet, cette requete comporte ici un formulaire : 
a completer par Putilisateur. > 
Le sous-module 70 retransmet lors d'une operation 182, cette* 
20 requete d'authentification active vers le serveur proxy 50 en utilisant le 
protocole iCAP, puis le serveur proxy 50 la retransmet, lors d'une operation 
184, vers le navigateur 16 en utilisant le protocole HTTP. Le navigateur 16 
affiche le formulaire qui permet a Putilisateur de s'identifier et de s'authentifier 
avec un niveau d'authentification superieur, par exernple, egal a "4" dans le cas 
25 du fournisseur de services 22. Une fois que le formulaire a ete complete, le 
navigateur 16 envoie, lors d'une operation 186, la reponse dans une requete 
HTTP. Cette reponse est interceptee par Pinterface 64 du serveur 50 et 
transmise, lors d'une operation 188, au sous-module 72 en utilisant le protocole 
iCAP. Le sous-module 72 retransmet alors, lors d'une operation 190, la reponse 
30 de Putilisateur en utilisant le protocole HTTP au serveur 24. Si le formulaire a 
correctement ete complete par Putilisateur, c r est-a-dire que le jeu d'informations 
d'identification et d'authentification est correcte, le serveur 24 memorise, lors 
d'une operation 192, le nouveau niveau d'authentification disponible dans la 
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memoire 40 et precede ensuite a I'operation 152. Les operations suivantes sont 
identiques a celles decrites en regard de la figure 2 a I'exception du fait que les 
operations 152, 156, 158 et 160 font intervener le sous-module 72 a la place du 
sous-module 70. 

5 La plupart des serveurs proxy existant comportent deja une interface 

iCAP. Ainsi, le systeme de la figure 2 simplifie la mise en ceuvre du precede 
SSO puisque la seule modification a apporter au serveur proxy consiste a le 
configurer de maniere a ce que I'interface iCAP intercepte les requetes HTTP 
necessaires a la mise en ceuvre de ce precede. 

10 La circulation des flux d'informations entre les differents elements du 

systeme 2 a ete decrite dans le cas particulier ou le serveur iCAP 60 
communique directement en utilisant le protocole HTTP avec le ou les 
fournisseurs de services lors des operations 156 et 158. En variante, le serveur 
iCAP communique avec les fournisseurs de services uniquement par 

15 I'intermediaire du protocole iCAP. Par exemple, dans cette variante, les. 
requetes HTTP emises a destination du fournisseur de services lors de 
I'operation 156 sont d'abord transmises par le serveur 60 jusqu'au serveur 
proxy 50 en utilisant le protocole iCAP puis le serveur proxy 50 transmet ces 
requetes au fournisseur de services en utilisant le protocole HTTP. La reponse 

20 HTTP emise par le fournisseur de services lors de I'operation 1 58 suit le chemin 
inverse de la requete emise lors de I'operation 156. Dans cette variante, le 
serveur 60 ne communique jamais directement avec les fournisseurs de 
services de sorte que ceux-ci ne sont pas au courant de I'existence du serveur 
60. ^utilisation du serveur 60 est alors totalement transparente pour ces 

25 fournisseurs de services. Cette variante presente I'avantage que du point de 
vue du fournisseur de sen/ices, tous les echanges d'informations se font entre 
lui et I'uiilisateur sans avoir ccnnsissance de Persistence- du serveur 60. Cena 
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sous-modules sont chacun implementes dans un serveur iCAP independant 
des autres. 

Ici, ('interface 64 est configuree pour n'intercepter que les requetes 
HTTP qui doivent etre traitees par le serveur iCAP. En variante, Pinterface 64 

5 est configuree pour rediriger tous les flux d'informations HTTP vers le serveur 
iCAP et le serveur iCAP implemente un module de filtrage propre a envoyer au 
module de traitement 66 uniquement les requetes HTTP qui doivent etre 
traitees par ce module. Ainsi, dans cette variante, Pinterception des requetes 
HTTP n'est pas realisee par le serveur proxy 50 mais par le serveur iCAP. 

10 Le systeme 2 a ete represents dans le cas particulier ou les serveurs 

d'authentification sont raccordes au fournisseur d'acces internet par 
Pintermediaire du reseau 4. En variante, au moins Pun de ces serveurs 
d'authentification est loge chez le fournisseur d'acces internet et raccorde a 
celui-ci par Pintermediaire d'un reseau local independant du reseau 4. Ce mode 

15 de mise en ceuvre avantageux lui permettra de beneficier de toutes les. 
identifications / authentications reaiisees par le fournisseur d'acces et qui m 
pourraient etre partagees avec des fournisseurs d'authentification extemes poun 
des raisons de securite; 

De meme, en variante, le serveur iCAP est raccorde au serveur 

20 proxy 50 par Pintermediaire d'un reseau grande distance et non plus par 
Pintermediaire d'une liaison ou d'un reseau local. 

Le systeme 2 a ete decrit dans le cas particulier ou la premiere 
authentification de chaque utilisateur est realisee par le fournisseur d'acces 
internet 12. En variante, cette premiere authentification n'est plus realisee par le 

25 fournisseur d'acces internet 12 mais, par exemple, par le premier fournisseur de 
services contacte par Putilisateur. 

Uidentification et I'authentification de Putilisateur ont ete decrites 
dans le cas particulier ou celle-ci se fait a partir d'un terminal 10 equipe d'un 
ecran et d'un clavier ce qui permet de saisir un jeu d'informations d'identification 

30 et d'authentification. En variante, la premiere identification et authentification de 
Putilisateur est realisee automatiquement, par exemple, en identifiant le terminal 
utilise par cet utilisateur. Plus precisement, lorsque le terminal 10 est rempiace 
par un telephone mobile, Pidentification et Pauthentification de Putilisateur se font 
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automatiquement en procedant a I'acquisition du numero de telephone du 
terminal. Dans ce cas, I'authentification est dite transparente. 

Le systeme 2 a egalement ete decrit dans le cas particulier ou les 
serveurs d'authentification memorisent uniquement le niveau d'authentification 
5 disponible pour chaque utilisateur ce qui renforce la securite du systeme 
puisqu'il n'est pas desirable que I'ensemble des mots de passe et autres 
informations secretes de I'utilisateur soient enregistres dans un meme lieu. 
Toutefois, en variante, ces serveurs d'authentification memorisent egalement 
en tant qu'informations d'authentification le ou les jeux d'informations 

10 d'identification et d'authentification que chaque utilisateur est susceptible 
d'utiliser pour s'identifier et s'authentifier aupres de chaque fournisseur de 
services. Ainsi, dans cette variante, la reponse d'authentification comporte le 
jeu d'informations d'identification et d'authentification a transmettre au 
fournisseur de services pour que celui-ci identifie et authentifie I'utilisateur. Ce 

15 jeu d'informations d'identification et d'authentification est transmis- au 
fournisseur de services de facon similaire a ce qui a ete decrit pour le certificat 
d'authentification. 

Le systeme 2 a ete decrit dans le cas particulier ou la requete 
d'authentification emise par chaque fournisseur de services comporte un niveau 

20 d'authentification. En variante, la requete d'authentification emise par I'un des 
fournisseurs de services ne comporte pas de niveau d'authentification. Dans 
cette variante, en reponse a cette requete d'authentification, le serveur 
d'authentification contacte fournit, en reponse, un certificat d'authentification 
indiquant simpiement que I'utilisateur a ete authentifie. Ainsi, dans cette 

25 variante, I'utilisateur aura acces aux services du fournisseur de services a partir 
du moment ou il a ete authentifie au moins une fois et ceci quel que soit le 
niveau de cetta authsntification. 
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lorsque ceux-ci ne disposent pas d'une authentification satisfaisante pour 
I'utilisateur. En variante, les serveurs d'authentification ne sont pas aptes a 
emettre ces requetes d'authentification actives. Des lors, dans cette variante, 
lorsqu'un serveur d'authentification est contacte alors qu'il ne possede, par 

5 exemple, aucune information d'authentification sur I'utilisateur, il est apte a 
emettre un message d'erreur a la place d'une requete d'authentification active. 

Finalement, le systeme 2 a ete decrit dans le cas particulier oCi le 
protocole de transfert de flux HTTP est le protocole iCAP. En variante, le 
protocole iCAP peut etre remplace par tout autre protocole de transfert de flux 

10 HTTP tel que par exemple le protocole OCP (OPES Call Out Protocol) avec 
OPES (Open Pluggable Edge Services). 

Le systeme 2 a ete defini en faisant reference aux recommandations 
etablies par Liberty Alliance. Toutefois, I'invention revendiquee n'est pas limitee 
aux systemes et aux precedes conformes aux recommandations de Liberty 

15 Alliance et s'appiique a tout systeme ou procede presentant des fonctionnalitea 
similaires a celles decrites ici. ?■ 
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REVEND1CATIONS 

1. Systeme d'acces a un reseau (4) a commutation de paquets 
adapte pour la mise en csuvre d'un precede a signature simplifiee, ce systeme 
comportant : 

5 - au moihs un poste d'utilisateur (10) equipe d'un navigateur 

internet (16), 

- un serveur proxy (50) par lequel passent tous les flux 
d'informations echanges entre le ou chaque poste d'utilisateur et ledit reseau, 

- plusieurs foumisseurs (20, 22) de services raccordes audit 
10 reseau (4), chaque fournisseur de services etant apte a emettre une requete 

d'authentification vers le poste de I'utilisateur qui le contacte pour identifier et/ou 
authentifier cet utilisateur avant de lui fournir des services personnalises et/ou 
securises, la reponse a fournir par un meme utilisateur a cette requete 
d'authentification pouvant etre differente en fonction du fournisseur de services 
15 contacte, 

- au moins un serveur d'authentification (24, 26) propre a 
mernoriser au moins une information d'authentification pour chaque utilisateur 
et a transmettre en reponse a une requete d'authentification une reponse 
d'authentification contenant une information d'authentification fonction a la fois 

20 du fournisseur de services ayant emis la requete d'authentification, et de 
I'identite de I'utilisateur ayant contacte ce fournisseur de services, et 

- un module (66) a signature simplifiee apte a traiter 
automatiquement en lieu et place du ou de chaque poste d'utilisateur les 
requetes d'authentification emises par les foumisseurs de services contactes, 

25 ce module etant apte pour chaque utilisateur : 

- a diriger les requetes d'authentification vers le serveur 
d'suihsntificaiion (24. 2G) approprie, ~i 
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(50) est equipe d'une interface (64) permettant de le raccorder au serveur 
supplementaire (60) et de transmettre au moins les requetes d'authentification 
emises par les fournisseurs de services contactes audit serveur supplementaire 
(60) pour traitement de ces requetes par le module a signature simplifiee (66). 

2. Systeme selon la revendication 1, caracterise en ce que le module 
a signature simplifiee (66) comporte un sous-module (70) propre a identifier 
I'utilisateur a partir de son adresse r6seau et a ajouter un identificateur de 
Putilisateur aux requetes d'authentification dirigees vers les serveurs 
d'authentification. 

3. Systeme selon Tune quelconque des revendications precedentes, 
caracterise en ce que ladite au moins une information d'authentification 
memorisee pour chaque utiiisateur comprend une information sur un niveau 
d'authentification disponible pour cet utiiisateur, en ce que chaque requete 
d'authentification emise par un fournisseur de services (20, 22) specifie des 
caracteristiques sur le niveau d'authentification requis par ce fournisseur de 
services pour pouvoir acceder aux services qu'il propose, en ce que le 
chaque serveur d'authentification (24, 26) est apte a comparer les 
caracteristiques sur le niveau d'authentification requis specifie par la requete 
d'authentification a I'information sur le niveau d'authentification disponible, .de 
maniere a determiner si le niveau d'authentification requis correspond au 
niveau d'authentification disponible pour cet utiiisateur, et en ce que le ou 
chaque serveur d'authentification (24, 26) est apte a emettre vers I'utilisateur 
une requete d'authentification active propre a activer sur le poste de I'utilisateur 
un processus interactif d'identification et/ou d'authentification de Putilisateur si le 
niveau d'authentification requis ne correspond pas au niveau d'authentification 
disponible. 

4. Systeme selon la revendication 3, caracterise en ce que le serveur 
supplementaire (60) comporte un sous-module (72) propre a diriger la reponse 
de I'utilisateur aux requetes d'authentification active vers le serveur 
d'authentification qui Pa emise. 

5. Systeme selon la revendication 3 ou 4 caracterise en ce que le 
serveur supplementaire comporte un sous module (70) propre a diriger la 
requete d'authentification active vers le poste de I'utilisateur. 
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6. Systeme selon I'une quelconque des revendications precedentes, 
caracterise en ce que le module a signature simplifiee (66) comporte un sous- 
module (68) capable d'ajouter aux requetes transmises par le poste d'utilisateur 
vers un foumisseur de services un signal ^identification de service a signature 

5 simplifiee en reponse auquel le foumisseur de services emet la requete 
d'authentification. 

7. Systeme selon I'une quelconque des revendications precedentes, 
caracterise en ce que le serveur supplemental (60) et le serveur proxy (50) 
sont aptes a communiquer Tun avec I 'autre en mettant en ceuvre un protocole 

10 de transfert de flux HTTP (Hyper Text Transfer Protocol). 

8. Systeme selon la revendication 7, caracterise en ce que le 
protocole de transfert de flux HTTP est ie protocole iCAP (Internet Content 
Adaptation Protocol) ou le protocole OCP (OPES Call Out Protocol). 

9. Systeme selon la revendication 7 ou 8, caracterise en ce que le 
15 serveur supplementaire (60) est uniquement apte a communiquer avec les . 

fournisseurs de services par I'intermediaire du protocole de transfert de flux 
HTTP mis en ceuvre entre lui et le serveur proxy (50). 

10. Systeme selon I'une quelconque des revendications 1 a 8, 
caracterise en ce que le serveur supplementaire (60) implemente egalement un 

20 serveur et/ou un client HTTP (Hyper Text Transfer Protocol) pour communiquer 
directement avec le ou chaque foumisseur de services et/ou le ou chaque 
serveur d'authentification uniquement a I'aide du protocole HTTP. 

11. Systeme selon I'une quelconque des revendications 
precedentes, caracterise en ce qu'il comporte un foumisseur d'acces (12) audit 

25 reseau (4) auquel doit se connecter le ou chaque poste (10) d'utilisateur pour 
pouvoir acceder audit reseau, ce foumisseur d'acces etant equipe du serveur 
prosy (50). 



21 

requetes d'authentification emises par le ou chaque fournisseur de services 
contacte, et est apte a communiquer avec un serveur proxy (50) pour recevoir 
au moins les requetes d'authentification emises par les fournisseurs de 
services. 
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Societe d'appartenance (facultaiif) 



1 1 1 1 1 1 1 4 000 CAEN 



FRANCES 



1 Q Norn 



Prenoms 



Adresse 



Rue 



Code postal et ville 



■ i i 
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